1. Field of the Invention
The present invention is related to programming techniques for operational policies in software applications, and more particularly to improved operational policy management infrastructure and related applications for dynamically updatable operational policies.
2. Description of the Background Art
The software development process typically involves various levels of debugging. The code in a software application is analyzed to find and eliminate programming errors or “bugs.” The debugging process takes place during the development process and typically continues throughout the life of the program through customer support. Initially, developers debug their assigned code modules until an executable version of the program is ready for testing. Then, alpha and beta builds are debugged based on interactions with a select few users. Ultimately, some level of debugging is generally involved with the various released builds of the software application, typically in the form of technical support teams dealing directly with customer problems. Often, this interaction leads up to updates and upgrades of the application itself.
To facilitate this complex debugging process during all the stages of the program, developers include special event-generating code in the application software that is not related to the business purpose of the program, i.e., the business logic or client code. The event generating code is related to the internal operation of the program and its main purpose is to provide information to that effect. This operational code helps the programmer identify sources of errors or warnings that may arise when the code is executed and to log important activities that can be useful in problem solving. Operational code is also used for testing and other purposes related to the maintenance of the code. For example, quality assurance processes involve regression testing as part of the software verification process. Such verification and testing functions also benefit from operational activities or events. Typically, operational code defines operational activities or events, e.g., logging, assertions, verifications, traces, and the like, and corresponding operational policy dictating a behavior for the program associated with the generated information, e.g., writing to output log files, breaking the debugger if in debug mode, beeping, displaying pop-up windows, and the like. In general terms, the operational policy is what defines a behavior associated with the information generated by the coded operational action or event.
Conventionally, the operational policy for each operational action is hard coded with the event-generating operational code. However, the operational policies often change throughout the development process. Initially, at early stages, developers embed in the code multiple operational events with detailed output policy to provide extensive information about the state of the system for debugging purposes. As errors are corrected and the code is revised, some of the operational behaviors are changed to reduce the level of detail reported, the intrusiveness of the output, and the overall performance of the code. In some cases, the operational code is removed if it is deemed no longer necessary. These operational policy changes are typically most significant between code builds: alpha builds, beta builds, and ultimately the release builds. However, it is difficult and time consuming to find all operational code and change it consistently when policies change.
A conventional approach to simplify the management of operational policies as requirements change between development stages and/or builds is to use the C/C++ notion of a macro. A developer places aliases for actual policy code in the source code, and then uses a preprocessor to replace the alias at compile time with the current policy code. This approach does not require the editing of multiple files but it does require recompiling after every change. With the same effect but with the additional requirement of editing every file when the policies change, another approach is to use source code editing scripts or macros. As new requirements arise or existing requirements change, the hard coded operational policies are automatically edited using pre-defined rules in scripts or macros, e.g., a find/replace-type script. Similarly, instead of editing every instance of operational code, a script can be used to edit in the source code certain parameter or variable values that are use in conditional statements in the code as part of the various operational events. For example, every operational event associated with a particular debugging purpose can include a condition for their execution that a certain variable be true. This way, in effect, the script can turn on or off the operational code for a particular debugging purpose by editing the variable value in the source code between true and false.
However, these conventional approaches to operational policy management based on editing scripts and macros require changes to the source code itself and/or subsequently the compiling of the new source code after the changes in order for the new operational policy to take effect. These approaches can be time consuming and inefficient when the source code is complex and requires lengthy compile times. Further, since they require editing and/or compiling the source code, these approaches cannot support dynamic updates to the operational policy, for example during runtime. Further, the code editing process itself can potentially become an additional source of errors, for example, by changing the wrong code. Another problem with conventional approaches is that people with different roles in the software development process (e.g. developers, QA, support, or the like), having differing needs policy-wise, either have to settle on policies that awkwardly try to meet the needs of many roles, or each role needs to compile a different version of the code with different policies defined.
Accordingly, what is needed is an operational policy management infrastructure that supports the ability to dynamically change the operational policies without having to change or recompile the client source code. What is further needed is an operational policy management infrastructure that decouples the operational policies from the source code authorship and compilation processes.